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MEMO 

To: Russ Larson 

From: D. Eyles 

Date: 9 March 1970 

Subject: What To Do About TLOSS For Apollo 14 

We are in a quandary over what to do about TLOSS for Apollo 14. The 
possibilities so far considered are these: 

(1) Do nothing. Be content with the Apollo 13 solution for the one most 
•time-consuming phase, P66 Auto. Time for the terrain model is provided by 
Covelli's synchronization of the LR read, so that the Apollo 14 rope is no less 
safe than the one for 13. This plan diverts little effort away from the variable 
guidance period being prepared for 15. 

(2) Generalize the scheme devised by Klumpp for P66 Auto to all powered 
flight. That is (a) raise Servicer's priority after it starts so a new Servicer 
cannot break in, and (b) check time at the end of Servicer and if it is too late 
(criterion in erasable) drop guidance for that pass. This would require fairly 
massive testing of the 14 rope, since every phase would have to be tested 

with enough TLOSS to drop off guidance. This is PCR 1012 as written. 

(3) Implement only part (a) of (2). This prevents the worst of the 
TLOSS manifestations - wild maneuvering - and nothing untoward happens 
before an eventual 1201 or 1202.alarm, except (here's the rub) some delta-V 
would be lost and the navigation thus degraded. So this version of PCR 1012, 
the one approved at the last SCB, does not seem too attractive. It could be 
improved by putting some alarm logic in a strategic place to warn if the duty 
cycle is being exceeded before any bad manifestations at all. But what would 
be the response to this alarm? Terminate the landing or continue and loose 
riavigation ? 

Up to now I have preferred solution (1). Thanks to Covelli the 14 rope 
would be better by a percent TLOSS or two even with the terrain model. But 
this memo is to point out another solution, a little bolder but possible and on 




the whole safer and easier. 


I suggest we offer the Variable Guidance Period Servicer - running at a 
minimum of 2 seconds to make it like current programs in the absence of 
TLOSS - for Apollo 14 with two to four weeks further slip, to mid-May or 
late. May. It could be done on roughly this schedule: 


now - 1C SFRR (mid-March) 
SFRR - next SCB (early April) 
SCB - end of April 
end of April - release 


Develop Variable Servicer in version 
Zerlina, minimizing computer usage. 

Test in Zerlina, concentrating on 
landing. 

Test all phases at 0 and some high 
value TLOSS (20% or 30%). 

Freeze assembly, run pseudo 
level 6 tests. 


The work done so far is consistent with this plan. The Variable Servicer 
is written and running in landings. The attractions of this plan are 

i 

(1) The variable Servicer - which as most here now agree, is the 
necessary ultimate solution to TLOSS worries - gets in one flight sooner. 


(2) Duplication of effort is avoided. The Apollo 14 effort does not detract 
from the more thorough plan for 15. 

V . 

(3) Minimization of total testing by eliminating the major difference 
there would be between the ropes for 14 and 15. Or, for a given amount of 
testing of these ropes, greater confidence would be gained. It seems silly to 
test another kluge for 14 when you expect to put in a non-kluge solution soon 
anyway. 

This suggestion is motivated by my discouragement with all the three 
initial suggestions and confidence in the variable Servicer now running in 
ZERLINA. 


